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System and Method to Provide Real Time Transaction 
Validation and Billing via a Communications Network 

Field of the Invention 

5 

The present invention relates to the billing and validation of transactions carried out via a 
communications network, and in particular, to the billing and validation of such 
transactions in which content may be delivered immediately via the communications 
network. 

10 

Background of the Invention 

The development of electronic commerce has to date relied generally upon the use of 
validation systems that predate the Internet and cellular telephones capable of digital data 

15 communication. For example, the purchase of software downloadable via the Internet 
has been possible for some time, but it is normally carried out using charge accounts. 
The customer selects software for purchase and provides a charge card number and other 
information to the software vendor via a secure encrypted connection. The software 
vendor then contacts the credit company by way of a separate channel using a digital 

20 protocol, and requests verification of the information that the customer provided. If all of 
the information is in order the credit company authorizes and guarantees the sale. Thus 
the vendor obtains validation from the credit company and allows the download to 
proceed 

25 Credit companies usually charge a percentage of the purchase price for their services. 
For this reason, the current systems for purchase of content via the Internet or other 
communications networks are in general not well suited to small purchases ("micro- 
payments") of, for example, less than a few dollars. An exception to this is the model 
used by telephone carriers for providing services such as directory assistance for a small 

30 charge and by the iMode cellular network system provided by NTT DoCoMo in Japan. 
In each case, the carrier itself either is the content provider (in the case of telephone 

1 
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carriers) or deals with the content providers (in the case of iMode) and provides the 
content directly to the user. While the iMode business model works for small amounts of 
data provided at low prices, it does not appear to be of interest to telephone carriers in 
North America, possibly due to the need to deal with a multitude of content providers. 

5 

A need exists for a method and system for validation of requests by customers for 
electronic content that (1) does not involve the validation service provider in the handling 
of large amounts of data representing the content and (2) is able to handle a variety of 
payment methods, including subscriptions, prepaid accounts, and micro-payments for 
1 0 content in a cost efficient manner for a large number of content providers. 

Summary of the Invention 

The inventive method and system provides real-time validation to a content provider of a 
15 customer's request, transmitted via a communications network, for delivery of content by 
the content provider to the customer, which delivery may be via the same 
communications network or other means. The inventive method includes (1) receiving a 
request for validation of a customer from the content provider, the request including data 
identifying the customer, (2) determining from the identifying data whether the customer 
20 is a subscriber, and (3) verifying that the customer request for service is not fraudulent, 
through direct contact with the customer or other means. 

"Real-time" herein shall mean in a time comparable or less than the time typically needed 
for a merchant to obtain validation of a credit card or debit card transaction. 

25 

The request for validation may include data identifying at least one characteristic of the 
content requested by the customer, such as the charge to be paid by the customer for the 
content If the customer's request is acknowledged and validation is sent to the content 
provider, then the charge to be paid is stored for later aggregation and billing to either the 
30 customer's account with the carrier of the communications system, the customer's charge 
account, or the customer' s prepaid account 

2 
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Further, the system can employ the use of digital signatures as part of the customer 
authorization of the transaction. The approval may be on a transaction originated by the 
content provider or on a transaction originated by the system. The digital signature of 
5 electronic documents may not require a payment transaction. 

Customers may have temporary identification data assigned to them by the 
communications system. The temporary identification data could be translated into a 
billing identity by the validation system so as to keep the customer's identity secret 

10 . 

Private or public key encryption methods may be used to verify the customer identity. 

Brief Description of the Drawings 

15 Figure 1 is a block diagram illustrating the flow of data in a transaction validation and 
billing system embodying the present invention. 

Figure 2 is a flowchart of a transaction validation and billing system embodying the 
present invention. 

20 

Figure 3 is more detailed depiction of the software abstractions of a transaction validation 
and billing system embodying the present invention. 

Detailed Description 

25 

The overall flow of data in the real-time transaction validation and billing system is 
illustrated in Figure 1. A customer 10 has decided to purchase content from a content 
provider 12. The system provides a transaction validation server 14 and a database 16, 
which interact with customer 10 and content provider 12 to validate a customer's request 
30 for content 20. The server 14 also provides billing information to credit or prepaid 
service providers 18. 
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More specifically, the customer 10 sends a request for content 20 to the content provider 
12 via a communications link 21 . The content requested may be electronic, such as an 
audio or video file, a software program, or a key to unlock a file or program on a storage 

5 medium such as a CD-ROM. While the system is primarily addressed to the problem of 
providing real time validation of the delivery of electronic content, it may also be used 
for the validation of transactions involving the physical delivery of goods or the provision 
of services, particularly transactions involving <fi micro-payments". For example, the 
"content" might be an item from a vending machine. Hence, "content" herein should be 

10 read widely to include anything that can be the subject of a commercial transaction. The 
delivery of content is indicated by reference numeral 32 in Figure 1 and is shown as 
taking place via the communications link 21, but it should be kept in mind that the 
content could be delivered in some manner other than the communication link 21 used by 
the customer 10 to make the request 20. 

15 

The content provider 12, upon receiving a request for content 20 from the customer 10, in 
turn sends a request for validation 22 to the transaction validation server 14 via a second 
communications link 23, which may be the same or a different form of communication 
from that used by the customer 10 to request the content The validation request 22 

20 includes data identifying the customer 1 0 and may include other data identifying the 

content The identifying data may be an identifier embedded in the validation request 22 
that is unique to customer 10. Suitable applets, custom software or application plug-ins 
may be required to facilitate the transmission of the appropriate identifier by the content 
provider 12 to the transaction validation server 14. The validation request 22 may also 

25 include a price to be charged for the content 

The transaction validation server 14, upon receipt of the validation request 22, sends a 
query 24 to the database 16 to obtain customer data 25, including records of what 
arrangements, if any, the customer 10 has made to pay for the content requested Such 
30 arrangements may include purchase of a prepaid billing plan or subscription, 

arrangements with the provider ("the carrier" herein) of the communications link 21 or an 
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agreement to pay by a credit card account The database 16 may also include purchase 
quantity or cost limits specified by the customer 10 in advance. The database 16 may 
also include historical data regarding previous validation requests and address data 
necessary for the transaction validation server 14 to send an immediate acknowledgement 
5 request 26 to the customer 10. 

The transaction validation server 14, assuming that the customer 10 is found in the 
subscription database 16 and is in good standing, then checks whether it is necessary to 
send an acknowledgment request 26 to the customer 10, as this requirement may be 

10 waived by some customers in predefined circumstances, or to some third party. If such a 
request is necessary the transaction validation server 14 sends the acknowledgment 
request 26 to the customer 10, or the third party, via a ted communications link 27, 
which may be the same as the communication link 21 used to communicate the request 
for content 20. If the customer 10 or third party confirms the request for content 20 by 

1 5 sending an acknowledgment 28 back to the transaction validation server 14, then the 
transaction validation server 14 in turn sends a validation 30 to the content provider 12 
over the second communication link 23 . The content provider 1 2 then in turn transfers 32 
the content to the customer 10. As discussed above, transfer 32 could include physical 
delivery of the content as well as electronic delivery via a communications network. 

20 

Preferably, the transaction validation server 14 also provides for billing the charges for 
each transfer of content 32 to the customer 10, although the content provider 12 could 
instead take care of the billing itself. A number of methods may be provided for doing 
so. For example, as shown in Figure 1, the transaction validation server 14 may send 
25 aggregated billing for content data 34 to a carrier, a charge card system such as VISA 
(TM), or a prepaid billing system. Alternatively, the customer 10 may have prepaid for 
transfers of content 32. All three alternatives are represented by the block labeled with 
reference numeral 18 in Figure 1 . 

30 An advantage of the inventive method is that many small charges may be aggregated and 
billed at one time. A further advantage is that the transaction validation server 14 does 

5 
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not handle the transfer of content 32. The transaction validation server 14 does not 
necessarily need to know what the content is, so long as the price to he charged is 
determinable and the customer 10 acknowledges the acknowledgment request 26, as per 
the pre-arranged method- Not only does the transfer of the content 32 not place a strain 
5 on the transaction validation server 14, but also the privacy of the customer 10 and the 
content provider 12 is maintained. In prior validation methods known to the inventors 
the content flows through a transaction server, requiring close involvement of the 
operator of the transaction server with the content provider. 

10 A further advantage of the inventive system and method is that the customer 10 may not 
need to enter any identification or password when requesting delivery of content For 
example, when communication link 21 is a wireless Internet system, the customer 10 is 
identified by the wireless device used, 

15 In the system described in relation to Figure 1, to simplify the description it has been 
assumed that the person initiating the request for content 20 is the same person who has 
the responsibility for paying the charges for the content In most cases that person will be 
a subscriber to a carrier that makes use of the validation and billing system described 
herein. However, there is no reason that the person initiating the request for content 20 

20 must be a subscriber. Suppose that a subscriber's child is the customer 10 and is with the 
permission of the subscriber operating a cellular telephone with digital data 
communication capabilities. This situation is illustrated in Figure 1 A, which differs from 
Figure 1 only in that the acknowledgement request 26 is sent out by the transaction 
validation server 14 to the subscriber, indicated by reference numeral 1 1, rather than to 

25 the customer 10, and the subscriber 1 1 replies with the acknowledgement 28, assuming 
that the subscriber 1 1 authorizes the content transfer 32. The content provider 12 and the 
transaction validation server 14 have no way of know whether the customer 10 and the 
subscriber 1 1 are the same person or not. 

30 A high level flowchart of the process employed by an embodiment of the transaction 
validation system of Figure 1 A that could be run on server 14 to provide real time 

6 
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transaction validation and billing as described above is shown in Figure 2. The process 
begins at block 50 by receipt by the transaction validation server 14 of a request 22 from 
a content provider 12 for validation of a customer's request for content 20. The request 
for content will include some identification of the source of the request for content 20. 
5 For example, the identification might be the unique hardware identifier of a digital 
cellular telephone, which is automatically sent whenever the cellular telephone is used. 
At block 52, the transaction validation server 14 verifies that the identification included 
in the request for content 20 matches that of a subscriber 1 1 . Note that matching at this 
stage does not mean that the request for content is valid and authorized by the subscriber 
10 1 1 as the cellular telephone could be stolen or the customer 10, who might not be the 
subscriber, could be attempting to obtain content that the subscriber 1 1 has not 
authorized. If there is no match at block 52, control passes to block 64, at which the 
content provider 12 is informed of the denial of the validation request 22. If there is a 
match at block 52, the transaction validation server 14 at block 54 checks to see if the 
15 subscriber 1 1 has preauthorized the charge for the content requested. If the subscriber 1 1 
has not, the transaction validation server 14 at block 56 sends an acknowledgement 
request26 to the subscriber 11. At block 58, if a response to the acknowledgement 
request 26 is received back in which acknowledgement is refused, or after some 
predetermined time limit, control is transferred to block 64 at which the content provider 
20 12 is informed of the denial of the validation request 22. If the subscriber 1 1 
acknowledges the request for content 20 within the time limit by returning an 
acknowledgement 28, then control is transferred to block 60 at which the transaction 
validation server 14 sends a validation 30 to the content provider 12. If the subscriber 1 1 
was found at block 54 to have preauthorized the charge for the content requested, then 
25 control also passes to block 60 at which the transaction validation server 14 sends a 

validation 30 to the content provider 12. Following execution of block 60, control passes 
to block 62 at which the charge for the content requested is added to an aggregate of 
charges for the subscriber 1 1 . Finally, the transaction validation process ends at block 68 
following either the execution of block 62 or block 64. 
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Figure 3 shows in more detail the software abstractions of an exemplary real-time 
validation and billing system, collectively referred to by reference numeral 100, which 
could implement core functions of the transaction validation server 14 and database 16 
and is the presently preferred embodiment of a real-time validation and billing system. In 

5 effect, Figure 3 is representation of how the system shown in simplified form in Figure 1 
could be implemented Each abstraction represents a process running on one or more 
computers or a database or portion of a database resident on one or more computers. For 
example, each database abstraction may represent a table or a set of tables of a single 
database structure and each process may be part of a single program running on a single 

10 computer. 

In Figure 3, communication between a customer 110 and the content provider 1 12 is 
assumed to be via a communications system 1 14. The communications system 114 could 
be the Internet or a service provided by a carrier. For the purposes of this example, it is 

15 assumed that the customer 1 10 is a subscriber to a wireless communications system 1 14 
operated by a carrier. The carrier's data processing facilities are represented in Figure 3 
by block 1 16 and include at least the capability of providing updated lists of the 
subscribers to the communications system 1 14. Communication between the content 
provider 1 12 and the system 100 is via a second communication system 115, which 

20 should preferably be a private network for security. Communication between the system 
100 and the customer 1 10 is via a third communication system 117, which may utilize 
system 1 14. For example, such communication may involve "tunneling" back through 
co mmuni cations system 115 and communication system 1 14. 

25 To further clarify the flow of data in the transaction validation system, the transaction 
validation server 14 in Figure 1 is represented in Figure 3 as several processes: a real- 
time billing handler 1 18; a subscriber handler 120; a rating services handler 122; a 
revenue distributor 124; and a marketing data collector 126. Likewise, the database 16 of 
Figure 1 is represented as several databases in Figure 3: 

30 
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a subscriber database 128, containing data on each subscriber, which may 
include identification of a rate plan selected by the subscriber, a desired 
currency for charges to the subscriber, and directions as to the conditions 
under which the subscriber will be asked to confirm transactions; 

a rate plans database 130, containing definitions of rate plans that may be 
selected by subscribers and may include methods for calculating the price to 
be charged for the content; 

a currency database 132, containing current exchange rates; 

a purchase history database 134, containing records of all transactions 
completed by the subscribers and content providers; and 

a revenue log database 136, containing a record of revenue attributed to the 
transaction validation service. 

Block 18 of Figure 1, which represents the carrier, charge card company, or prepaid 
billing company has been expanded in Figure 3 into two blocks: the carrier 1 16 and a 
20 financial institution 140, which may be a wallet or credit company, prepaid company, or 
a bank. 

Data flows in the System 100 are now described. Upon receipt of a request for content 
from the customer 1 10 via communication system 114, the content provider 1 12 sends a 
25 query via communication system 115 containing data identifying the customer 110 and 
the content requested to the real-time billing handler 118 asking for validation of the 
customer's request for content. The real-time billing handler 1 18 creates a transaction 
object containing at least the data received from the content provider 1 12 and in turn 
sends a query to the subscriber handler 120 referencing the transaction object. 

30 
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Using the customer identification data in the transaction object, the subscriber handler 
120 queries the subscriber database 128 to determine whether there is a current subscriber 
whose customer identification data matches that received by the real-time billing handler 
1 18 from the content provider 1 12. If no match is found in the subscriber database 128, 
5 the subscriber handler 120 checks the carrier's data processing system 1 16 to determine 
whether the customer 1 1 0 is a current subscriber. This determination may optionally be 
done even if the customer 1 10 is found in the subscriber database 128 or may be done in 
lieu of checking subscriber database 128. 

10 If the customer 1 10 is determined to be a subscriber to the communication system 1 14 
provided by the carrier 116, then the subscriber handler 120 will ask the rating services 
handler 122 for the price to be charged for the content requested by the customer 110. 
The rating services handler 122, using the data contained in the transaction object, 
queries the subscriber database 128, to determine which rate plan should be applied to the 

15 transaction, the rate plan database 130 to determine a price to be charged for the 

requested content based upon the rate plan to be applied and the identification of the 
content, and the currency database 132 for the proper exchange rate, if any, to be applied 
t» the price so as to calculate the price in the preferred currency of the customer 110. The 
rating services handler 122 reports the price for the transaction back to the subscriber 

20 handler 120. 

The subscriber handler 120 then, if the data found in the subscriber database 128 
indicates that the price is to be charged to the customer's account with the financial 
institution 140, may seek preauthorization from the financial institution 140. If 
25 preauthorization is refused, the subscriber handler 120 reports back to the real-time 
billing handler 118, which in turn reports to the content provider 1 12 and closes the 
transaction. 

If no preauthorization is required or if preauthorization is given by the financial 
30 institution 140, the subscriber handler 120 communicates the final price to the customer 
1 10 as part of an acknowledgment request sent via communications system 1 17 and then 

10 
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waits for an acknowledgment from the customer 10. If the subscription database 128 
contains special instructions regarding acknowledgment, then the acknowledgment 
request will instead be directed to a third party or the transaction automatically confirmed 
or rejected based upon customer-defined price thresholds. When a decision is reached, 
5 the subscriber handler 120 responds accordingly to the real-time billing handler 118. The 
real-time billing handler 118 then informs the content provider 1 12 as to the decision 
(shown in Figure 1 as a validation 30). 

If the content provider 110 receives validation from the real-time billing handler 118, 
10 then the content provider 1 10 commences providing the content. When the content 
provider has finished providing the content, it sends a service complete message to the 
real-time billing handler 118. This informs the real-time billing handler 1 18 to close the 
transaction and report to the rating services handler 122 that the transaction is closed. If 
the content is to be provided over an extended period in response to separate requests for 
15 content from the customer 1 10, e.g., the content is a subscription to a service that 

provides updated information for a specified time period for a fixed total fee, then the 
transaction is kept open and on receipt of validation requests from the content provider 
1 12, the billing handler 118 may only ask the subscriber handler 120 to confirm that the 
customer 110 remains in the subscriber database 128. No acknowledgment may be 
20 needed from the customer 1 10. 

When a transaction is finally completed by the receipt of a service complete message, the 
billing handler 118 notifies the rating services handler 122, which in turn closes 
transaction object and the passes data regarding the transaction on to a revenue distributor 

25 handler 1 24. The data passed to the revenue distributor handler 1 24 may include data 
from the rate plans database 130, the currency database 132, and the purchase history 
database 134 in addition to the details of the transaction just closed. The revenue 
distributor handler 124 stores the details of the just closed transaction in the purchase 
history database 134 and determines which method was chosen by the customer 1 10 for 

30 payment based on information from the rating services handler 122. Depending upon the 
payment method chosen, the revenue distributor handler 124 sends the appropriate data 
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on to the financial institution 140 or the carrier 116. Finally, a log is made of the revenue 
to be attributed towards the operation of the system 100 by storing appropriate data in 
revenue log database 136. 

5 Subscribers may be provided with means for reviewing transactions and options such as 
redirecting acknowledgment requests to a device other than that from which a request for 
content 20 originated. For example, the subscriber may be a parent and the customer 1 10 
at a given time may be the parent's child. In that case, the subscriber may wish to have 
acknowledgment requests 20 sent to the subscriber rather than the customer 1 10, if the 

1 0 transaction involves more than a preset cost or content other than preset content. Such 
data may be stored in the subscriber database 128 for use by the subscriber handler 120. 

Optionally, the marketing data collector handler 126 may extract data from the purchase 
history database 134 to aggregate and summarize data for the carrier 1 16 or possibly 
15 other planning uses. Further, the revenue distributor handler 124 can query the purchase 
history database 134 for statistics, reports, or dispute resolution. For example, disputes 
involving micro-payments may be handled automatically by reversing charges to a 
customer's account unless the purchase history database 134 contains evidence that 
suggest abuse of the system by the customer. 

20 

The identity of the customer 110 may be kept secret from the content provider 1 12 by use 
of temporary identification data assigned by the carrier 116 and used by the customer 110 
to communicate with the content provider 112 and receive content via the 
communications system 1 1 4, if the content is to be provided via that system. Only the 

25 temporary identification data would be sent to the content provider 1 12 by the customer 
110 during the request for content. The correspondence between the temporary 
identification data and the identity of the customer 1 10 would be available to the 
subscriber handler 120 for validation and billing purposes, but the identity of the 
customer 110 would not be provided to the content provider 1 12. The temporary 

30 identification data may be set up as part of the subscription process by the carrier 116 and 
may be changed periodically thereafter or may be assigned dynamically by the carrier 
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116 each time the customer 110 uses the device. Further, digital signatures may be used 
in all communications between the customer 1 10, the content provider 1 12 and the 
system 1 00. As well, private or public key encryption methods may be used to protect 
and verify customer identity. 

The transaction validation and billing system and method described above may be 
implemented in a variety of ways. Those skilled in the art will understand that the above 
description enables the implementation of the invention using other combinations of 
computers and communication networks. 
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What is claimed is: 

1 . A computer method for providing real-time validation to a content provider of a 
customer's request transmitted via a first communication method for delivery of content by the 
content provider to the customer, the method comprising: 

maintaining a subscriber database containing data identifying subscribers; 

receiving from the content provider a request for validation of the customer's request, the content 
provider's request including data identifying the customer; 

querying the subscriber database to determine whether the data identifying the customer matches 
that corresponding data for a subscriber; 

if the data identifying the customer matches that corresponding data for a subscriber, then 
requesting via a second communication method acknowledgment from the subscriber of the 
request for the delivery of the content; and 

upon receipt of an acknowledgment from the subscriber, sending to the content provider a 
validation of the customer's request. 

2. The method of claim 1, wherein the first and second communication methods use a 
common communication system. 

3. The method of claim 2, wherein the common communication system is a wireless system. 

4. The method of claim 1 , wherein the request for validation includes data identifying at 
least one characteristic of the content requested by the customer. 

5. The method of claim 4, wherein the identifying characteristic is a charge to be paid by the 
customer if the customer's request is acknowledged and validated to the content provider. 

14 
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6. The method of claim 5, additionally comprising billing the charge to the subscriber, if the 
customer's request is acknowledged and validation is sent to the content provider. 

7. The method of claim 6, wherein: 

the charge, if acknowledged and validated to the content provider, is aggregated with charges 
corresponding to other content that has in a similar manner been requested by the customer, 
acknowledged by the subscriber, and the transaction validated to the relevant content providers; 
and 

the aggregated charges are periodically billed to the subscriber. 

8. A computer system for providing real-time validation to a content provider of a 
customer's request transmitted via a first communication method for delivery of content by the 
content provider to the customer, the system comprising: 

a subscriber database server containing data identifying subscribers; 

a first communication interface for sending data to and receiving data from the content provider 
via a second communication method; 

a second communication interface for sending data to and receiving data from the subscribers via 
a third communication method; and 

a processor for 

processing data received by the first communication interface requesting validation of the 
customer's request, the request received including identification data, 

querying the subscriber database to determine whether the identification data matches 
corresponding data for a subscriber, 

15 
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if the identification data matches corresponding data for a subscriber, causing the second 
communication interface to send data requesting acknowledgment from the subscriber of 
the request for the delivery of the content, and 

upon receipt of an acknowledgment by the second communication interface from the 
subscriber, causing the first communication interface to send to the content provider a 
validation of the customer's request. 

9. The system of claim 8, wherein the request for validation includes data identifying at 
least one characteristic of the content requested by the customer. 

1 0. The system of claim 9, wherein the identifying characteristic is a charge to be paid by the 
subscriber if the customer's request is acknowledged and validated to the content provider. 

11. The system of claim 10, wherein the processor bills the charge to the subscriber if the 
customer's request is acknowledged and validation is sent to the content provider. 

12. The system of claim 11, wherein: 

the charge, if acknowledged and validated to the content provider, is aggregated with charges 
corresponding to other content that has in a similar manner been requested by the customer, 
acknowledged by the subscriber, and the transaction validated to the relevant content providers; 
and 

the aggregated charges are periodically billed to the subscriber. 
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